A Multimedia Intensive Collaborative Environment (hereinafter referred to as a MICE) is a broadband communication network that typically contains a plurality of host devices or hosts. A host is defined herein as a source when it transmits one or more feeds or streams of data (e.g., video data, audio data, etc.) within the MICE. A host is defined herein as a client when it receives one or more feeds transmitted by one or more sources within the MICE. Typically the MICE is an Internet Protocol (IP) enabled network, wherein the data is transmitted from the sources to the clients using the Internet Protocol as defined, for instance, in Internet Engineering Task Force (IETF) Request For Comment (RFC) 791 and RFC 2460. Moreover, in most networks the data may be of a high resolution (i.e., bandwidth intensive) and may be transmitted using either a unicast or a multicast method of transmission. Using the unicast method, a feed is transmitted by a specific source to a specific client. Whereas using the multicast method, feeds from one or more sources are sent to a “host group” (also referred to herein as a “multicast group”) wherein each client that is a member of the host group receives all of the feeds transmitted to the host group.
Examples of MICEs include Access Grid Nodes, airport security systems with video surveillance, and public safety command-and-control multimedia systems. Typically the devices connected to the MICE comprise machines such as personal computers that have the necessary resources and/or capabilities to receive all of the feeds sent to a multicast group to which the machine is a member. However, to extend the functionality of the system, it may be desirable to introduce a device having more limited resources and/or capabilities (also referred to herein as a resource-constrained device or RCD). The limited resources and/or capabilities may result from, for instance, the RCD having reduced processing speed, available bandwidth, etc. or the RCD being limited to receiving one kind of data (e.g., only audio data). Examples of an RCD include, but are not limited to, a handheld device, a cellular telephone, a radio, a personal digital assistant (PDA), etc.
Due to the limited resources and/or capabilities of the RCD, there are some problems associated with introducing the RCD into the MICE. For example, if the RCD simply tried to join a multicast group, it may become overwhelmed by the bandwidth required to receive all of the feeds, or it may not have the capabilities to receive every kind of feed transmitted into the multicast group. There are some existing solutions that address the problems associated with the RCD receiving data sent to various multicast groups, but these solutions have several disadvantages.
One such solution involves upgrading the hardware resources on the RCD to enable the reception of all of the feeds available to the RCD. However, in many cases, this solution is impractical. For instance, a handheld device with these additional hardware resources may become too bulky to serve its purpose of being portable, and the upgrade may also be too costly. Moreover, as the resources available to a handheld device increase, in general so will the amount, type and bandwidth of the data being transmitted in the MICE. Therefore, resources of a handheld device will typically always lag behind the amount, type and bandwidth of the data available to the handheld, thereby potentially leading to the handheld becoming overwhelmed upon being connected within the MICE.
A second solution involves using a proxy or gateway device to redirect to one or more RCDs a subset of the feeds transmitted into one or more host groups. The subset will put a lower strain on the RCD. However, since all traffic is filtered through the proxy device, the proxy device introduces a single point of failure and may, moreover, become a bottleneck as the number of sources within the MICE increases. Furthermore, as the number of RCDs served by the proxy device increases, the complexity of the proxy device will typically correspondingly increase.
A third solution involves implementing a Source Specific Multicast (SSM) as defined, for instance, in IETF RFC 3569. With SSM, a client can request and receive data from selected sources in selected groups. More specifically, SSM provides a network layer service of a “channel” that is characterized by a source group (S, G) pair that identifies a source having a corresponding IP address and a group into which the source transmits one or more data streams, the group also having a corresponding IP address. A client can receive a source's feed(s) on a channel by subscribing to the channel's (S, G) pair. Channel subscription is supported by version three (3) of the Internet Group Management Protocol (IGMP) for IPv4 and version two (2) of the Multicast Linear Discovery (MLD) Protocol for IPv6, in accordance with, for instance, an IETF Internet Draft dated Oct. 1, 2004. However, RFC 3569 only provides for a partial solution in that it fails to address a particular methodology for a client to become aware of appropriate channels to which the client may subscribe.
Thus, what is needed is more effective methods and apparatus for a client in a multicast environment to discover and subscribe to selected channels in a network for receiving data. It is further desirable that the methods and apparatus be compatible with a source filtering protocol such as, for instance, SSM.